Conversation
…or had already started in May
| There is usually either one or two maintenance branches at any given time. | ||
| After the final release of a new minor version (3.x.0), releases |
There was a problem hiding this comment.
It's always Python 3.x, we don't care about 2.x any more.
If there's a 4.x, and things change, we'll update it then.
| changes to the branch. After the final release is published, the full | ||
| :ref:`development cycle <stages>` starts again for the next minor version. |
There was a problem hiding this comment.
Incorrect.
After the final release is published in October, the dev cycle for the next one had already started back in May.
There was a problem hiding this comment.
Maybe add that this period starts after RC1? Or at least it has for the last couple of releases.
There was a problem hiding this comment.
The new dev cycle begins after beta 1, when main forks to a 3.x branch.
I think let's keep these explanations simpler, about the current cycle, rather than matching them up to previous/next cycles.
| changes to the branch. After the final release is published, the full | ||
| :ref:`development cycle <stages>` starts again for the next minor version. |
There was a problem hiding this comment.
Maybe add that this period starts after RC1? Or at least it has for the last couple of releases.
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
3 participants
📚 Documentation preview 📚: https://cpython-devguide--1681.org.readthedocs.build/